.TH "twin" "1" "0.6.3" "" ""
.SH "NAME"
twin \- a Textmode WINdow environment
.SH "SYNTAX"
.B twin [OPTION [...]]
.SH "NOTE"
This manual page uses some parts of /usr/local/share/doc/twin/Tutorial.
you should look at this file if you need further info.
.SH "DESCRIPTION"
Twin creates, draws and manages windows inside a text display.
It implements in text mode the same concepts that X11 does in graphics:
.PP
a. draw on some kind of screen (tipically a computer monitor).
.PP
b. allow multiple windows to coexist on the same screen, and draw independently on each of them.
.PP
c. talk to external programs (even on other machines) so that the programs receive keystrokes, mouse movements, etc. and can send back drawing commands.
.PP
Twin runs on the linux console, inside itself, in a twin terminal and on X11: it creates a window and draws in it, does not run inside an xterm or similar. It can also run on generic text terminals (ttys) using the termcap/ncurses driver, but it will work far from optimal.
.SH "OPTIONS"
.TP
\fB\-h\fR, \fB\-\-help\fR
display this help and exit
.TP
\fB\-V\fR, \fB\-\-version\fR
output version information and exit
.TP
\fB\-x\fR, \fB\-\-excl\fR
start display as exclusive
.TP
\fB\-\-nohw\fR
start in background without display
.TP
\fB\-\-hw=<display>[,options]\fR
start with the given display (multiple \-hw=... allowed)
.TP
Currently known display methods:
 X[@<XDISPLAY>]
 xft[@<XDISPLAY>]
 twin[@<TWDISPLAY>]
 tty[@<tty device>]
.SH "FILES"
\fI~/twinrc\fP configuration file for the Twin user interface
.br .br
\fI~/.TwinAuth\fP holds some magic data that clients use to answer the challenge received from twin. See Security section.
.SH "ENVIRONMENT VARIABLES"
.TP
\fBTWDISPLAY\fP
Specifies the Twin server to be used.
Twin can create a window on another twin server and use it as display.
.TP
\fBDISPLAY\fP
Specifies the X11 server to be used.
Twin can create a window on an X11 server and use it as display.
.SH "SECURITY"
The authorization method currently used vaguely resembles Xauthority:
the file .TwinAuth in your home directory holds some magic data that clients use to answer the challenge received from twin.
If that data is wrong or the file doesn't exist, clients can connect to twin only using the unix socket (TWDISPLAY=:<something>)
so they must run on the same machine as twin; remote programs won't be able to connect.
Also, the unix socket is set to permissions 600, so only the owner can connect to it (at least on Linux it works this way).
The `challenge' is actually an MD5 checksum verification: server sends 256 bytes of random data; client does MD5 of that data
+ .TwinAuth and sends MD5 back. If server agrees on MD5, it grants connection. This challenge method has an important feature:
The contents of your .TwinAuth is NEVER transmitted through any socket. So, unless your home directory resides on an NFS filesystem,
you can be sure that noone will be able to find the data contained in your .TwinAuth by spying the network between twin
and the clients you start. On the other hand, the connection between twin and clients is NOT encrypted,
so it is easy to find out what you type and what you see in the client windows by spying the network as above.
.SH "EXAMPLES"
run a twin server, and let it try to autodetect the type of display (X11, tty or twin):
.LP
.B twin
.PP
run a twin server, specifying to create an X11 window to use as display:
.LP
.B twin \-\-hw=X
.SH "AUTHORS"
Massimiliano Ghilardi <paperinik@users.sourceforge.net>
.SH "SEE ALSO"
